Digging around a bit, it seems that neither Browserify¹ nor Webpack 4² would use that field. Is this field meant for other tools/versions? Or is it mean to be browser at top level, which both would understand (but double up with main which they already understand).

@romaricpascal Sorry I didn't explain very well 😆

Remember we tried compiling separate CommonJS modules?

This PR would let unpkg, webpack 4 and Browserify stay on top-level "browser" as UMD

But modern bundlers get require() or import (with tree-shaking) via package exports as CommonJS, but we'd still offer a route for those applying a "browser" condition to get bundles if needed

None of these tools mention a browser field inside exports for getting their dependency (webpack and Browserify talk about one at the top level of package.json, and Unpkg mentions its own unpkg field). So what I was trying to clarify is whether the configuration was in the right place.

Thinking on it some more, I think until we get a clear demand for automatically linking to an UMD build for these old bundlers, we should avoid adding more complexity to our exports. People can require the relevant path in their code, so wouldn't be blocked. That's also one less path that govuk-frontend may resolve to, which simplifies support.

If demand comes in, though, happy to look into it further. The change wouldn't be breaking anyway as people using the full path wouldn't be forced to make the update.

Yeah, don't worry, hope it's clearer now

Definitely, we split this PR out when CommonJS was removed in #3726 (comment)

Won't need looking at again unless we drop UMD as the default for require()